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CHAPTER  7 

Packet  Telemetry  Downlink 

This  standard  defines  the  method  for  transporting  variable-length,  well-defined  data 
formats  in  a  Chapter  4  pulse  code  modulation  (PCM)  stream. 

7.1  Packet  Telemetry 

Packet  telemetry  (PT)  defines  the  method  for  asynchronously  inserting  data  from  one  or 
more  data  streams  into  PCM  minor  frames.  This  standard  defines  various  PT  packet  types  that 
are  used  to  encapsulate  well-defined  data  formats,  including: 

•  Chapter  10  packets; 

•  Chapter  24  TmNSMessages; 

•  Ethernet  frames. 

A  PT  packet  is  encapsulated  into  an  integral  number  of  packet  telemetry  data  packets 
(PTDPs)  -  nominally  each  PTDP  contains  only  one  PT  packet.  Different  PT  packet  types  may 
be  multiplexed  simultaneously  into  a  single,  logical  stream  of  PTDPs,  which  is  then  segmented 
into  fixed-length  packet  telemetry  data  frames  (PTFRs)  that  are  inserted  into  a  PCM  stream. 
While  a  PTFR  may  be  segmented  and  interspersed  with  PCM  data  within  a  PCM  minor  frame, 
each  PCM  minor  frame  shall  contain  only  one  PTFR.  A  low-latency  PTDP  (FFP)  mechanism 
allows  for  the  insertion  of  one  or  more  PTDPs  with  low-latency  requirements  into  the 
transmission  of  a  long  PTDP.  Specific  structure-critical  elements  are  protected  using  a  Golay 
code;  see  Appendix  7- A  for  details.  Figure  7-1  provides  an  overview  of  the  entire  packet 
telemetry  encapsulation  process. 
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Figure  7-1.  Packet  Telemetry  Overview 


NOTE 


y 


A  PT  packet  may  be  fragmented  into  multiple  PTDPs  where  each  PTDP’s 
payload  contains  a  fragment  of  the  PT  packet.  Subsection  7.2.3  describes 
PT  packet  fragmentation. 


A  PTFR  may  be  segmented  for  insertion  into  a  PCM  minor  frame.  A  single 
PCM  minor  frame  may  contain  multiple  PTFR  segments.  See  Section  725 
for  more  details. 


NOTE 


y 


The  IRIG  106-15  restricted  a  PCM  minor  frame  to  a  single, 
complete  PTFR.  The  current  standard  supports  multiple  PTFR 
segments  per  PCM  minor  frame. 


NOTE 

Chapter  9  supports  defining  PTFR  segments  contained 

within  a  PCM  minor  frame. 

7.2  Packet  Telemetry  Data  Packet  Structure 

A  PTDP  shall  include  a  header  and  a  payload  as  shown  in  Figure  7-2. 
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PTDP  HEADER 
(2x12  bits  unencoded  = 

2  x  24  bits  Golay-encoded) 
PTDP  PAYLOAD 

_ (variable  length) _ 

Figure  7-2.  PTDP  Structure 


7.2.1  PTDP  Header 

The  PTDP  header  shall  consist  of  two  12-bit  words  and  shall  be  encoded  as  two  24-bit 
Golay  code  words  prior  to  insertion  into  the  PTDP,  encoded  most  significant  bit  (msb)  first  and 
in  the  word  order  as  shown  in  Figure  7-3. 


11  10 

9  8  7  6 

5  4 

3  2  10 

Word  0 

Reserved 

Content 

Fragment 

Length  (15-12) 

Word  1 

Length  (11-0) 

Figure  7-3.  PTDP  Header  Structure  (Unencoded) 


The  PTDP  header  consists  of  the  following  fields. 

•  Reserved  (bits  23  -  22).  All  bits  shall  be  set  to  zero  (e.g.,  2’b00)  on  transmission; 
ignored  on  reception. 

•  Content  (bits  21  -  18).  The  PT  packet  type  field  shall  specify  the  type  of  PTDP 
payload  (see  Subsection  7.2.2  for  details). 

o  4’b0000:  PT  Fill  Packet 

o  4’b0001:  PT  Application-Specific  Packet 

o  4’b0010:  PT  Test  Counter  Packet 

o  4’b0011:  PT  Chapter  10  Packet 

o  4’b0100:  PT  Raw  Ethernet  Media  Access  Control  (MAC)  Frame  Packet 

o  4’b0101:  PT  Internet  Protocol  (IP)  Packet 

o  4’b01 10:  PT  Chapter  24  TmNSMessage  Packet 

o  4’b0111  - 

4’bllll:  Reserved 


•  Fragment  (bits  17  -  16).  The  PT  packet  fragmentation  flags  shall  identify  whether 
the  PTDP  payload  contains  a  complete  PT  packet  or  a  fragment. 


o 

2’b00: 

Complete  PT  Packet 

o 

2’b01: 

First  Fragment  of  a  PT  Packet 

o 

2’blO: 

Middle  Fragment  of  a  PT  Packet 

o 

2’bll: 

Last  Fragment  of  a  PT  Packet 

•  Length  (bits  15-0).  The  PTDP  length  field  shall  provide  the  length  (in  bytes)  of  the 
PTDP  payload  (note  the  PTDP  header  length  is  not  included  in  the  PTDP  length).  If 
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a  PT  packet  exceeds  the  maximum  PTDP  length,  the  PT  packet  must  be  fragmented 
using  multiple  PTDPs  as  specified  in  Subsection  7.2.3. 

7.2.2  PTDP  Payload 

The  PTDP  payload  shall  contain  either  a  complete  PT  packet  or  a  PT  packet  fragment 
and  the  Content  field  identifies  the  type.  The  following  subsections  contain  a  detailed 
description  for  each  PT  packet  type. 

7.2.2. 1  PT  Fill  Packet 

If  no  PT  packets  are  available  for  embedding  into  a  PTDP  stream,  PT  fill  packets  shall  be 
generated  and  inserted  into  the  PTDP  stream  to  assure  a  constant  data  flow  to  the  PCM  stream. 
Each  PT  fill  packet  byte  shall  be  set  to  8’bl0101010  (OxAA)  as  shown  in  Figure  7-4.  A  PT  fill 
packet  size  may  be  an  arbitrary  integral  number  of  bytes. 


7  0 

7  0 

7 

0 

7  0 

10101010 

(OxAA) 

10101010 

(OxAA) 

10101010 

(OxAA) 

ngure  7-4. 

JT  Fill  Packet 

1 .2.2.2  PT  Application-Specific  Packet 

This  standard  does  not  define  the  format  of  PT  application-specific  packets.  While  PT 
application-specific  packets  are  allowed,  they  shall  not  be  used  to  encapsulate  data  that  conforms 
to  another  defined  PT  packet  format  (e.g.,  Chapter  10  packets,  Chapter  24  TmNSMessages, 
Ethernet  data,  etc.). 

7. 2. 2. 3  PT  Test  Counter  Packet 

The  PT  test  counter  packet  is  defined  as  a  free-running  12-bit  counter.  The  PT  test 
counter  packet  shall  consist  of  one  12-bit  word  and  shall  be  encoded  as  one  24-bit  Golay  code 
word,  encoded  msb  first  as  shown  in  Figure  1-5. 


Figure  7-5.  PT  Test  Counter  Packet  (Unencoded) 


NOTE 


The  test  counter  packet  is  optional  and  this  standard  does  not 
specify  the  transmission  rate. 


7. 2. 2.4  PT  Chapter  10  Packet 

The  PT  Chapter  10  packet  structure  contains  a  slightly  modified  version  of  a  Chapter  10 
packet.  The  primary  differences  between  the  original  Chapter  10  packet  header  and  the  PT 
Chapter  10  header  are: 

•  The  PT  Chapter  10  packet  does  not  contain  the  packet  sync  pattern  field; 

•  The  PT  Chapter  10  packet  does  not  contain  the  packet  length  field; 

•  The  PT  Chapter  10  packet  contains  a  packet  trailer  bytes  field; 
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•  The  PT  Chapter  10  packet  may  contain  fewer  fill  bytes  than  the  original  Chapter  10 
packet  header. 

Subsection  7.2.2.4.1  describes  PT  Chapter  10  packet  composition.  Subsection  7.2.2.4.2 
describes  Chapter  10  packet  reassembly. 

Figure  7-6  shows  the  Chapter  10  general  packet  structure  and  Figure  7-7  shows  the  PT 
Chapter  10  packet  structure. 


Chapter  10 
Packet  -■ 
Header 


31  24 

23  16 

15  8 

7  0 

Channel  ID 

Packet  Sync  Pattern 

Packet  Length 

Data  Length 

Data  Type 

Packet  Flags 

Sequence  Number 

Data  Type  Version 

Relative  l  ime  Counter  (low) 

1  leader  Checksum 

Relative  l  ime  Counter  (high) 

Packet  Secondary  Header  (optional) 

Packet  Body 

Packet  Trailer 

Figure  7-6.  Chapter  10  General  Packet  Structure 


PT 

Chapter  10 
Header 


PT  Chapter  10  Header  Protected  Fields 
(4x12  bits  unencoded  = 

4  x  24  bits  Golay-encoded) 

PT  Chapter  10  Header  Unprotected  Fields 
(12  bytes) 

Packet  Secondary  Header  (optional) 

Packet  Body 

Packet  Trailer 

Figure  7-7.  PT  Chapter  10  Packet  Structure 


The  original  Chapter  10  packet  header  fields  are  partitioned  into  two  groups  for  the  PT 
Chapter  10  header: 

•  Golay-encoded  protected  fields  that  protect  structure-critical  header  information; 

•  Unprotected  fields. 
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The  PT  Chapter  10  header  protected  fields  shall  consist  of  four  12-bit  words  and  shall  be 
encoded  as  four  24-bit  Golay  code  words  prior  to  insertion  into  the  PTDP  payload,  encoded  msb 
first  and  in  the  word  order  indicated  in  Figure  7-8. 


11  \  10  \  9  \  8  \  7 

6  |  5  |  4 

3  \  2  \  1  \  0 

Word  0 

Reserved  (0) 

Channel  ID  (15  -  12) 

Word  1 

Channel  ID  ( 1 1  -  0) 

Word  2 

Packet  Trailer  Bytes1  (4  -  0) 

Data  Length2  (18-12) 

Word  3 

Data  Length2  (11-0) 

1  The  pac 
secondary 
Subsectio 

2  The  Dat 
sizes,  exc 
Subsectio 

cet  trailer  bytes  shall  contain  the  sum  of  the  PT  Chapter  10  packet’s 
header  length,  fill  bytes  length,  and  packet  checksum  length.  See 
n  7. 2.2.4. 1. 

a  Length  field  size  limit  of  19  bits  is  sufficient  for  all  Chapter  10  packet 
ept  Computer-Generated  Data  Packet,  Format  1  setup  record.  See 
n  7. 2.2.4. 1. 

Figure  7-8.  PT  Chapter  10  Header  Protected  Fields  (Unencoded) 


The  PT  Chapter  10  header  unprotected  fields  shall  consist  of  12  bytes  as  shown  in  Figure 
7-9. 


31  24 

23  16 

15  8 

7  0 

Data  Type 

Packet  Flags 

Sequence 

Number 

Data  Type 
Version 

Relative  Time  Counter  (low) 

Header  Checksum 

Relative  Time  Counter  (high) 

Figure  7-9.  PT  Chapter  1C 

Header  Unprotected  Fields 

7. 2.2.4. 1  PT  Chapter  10  Packet  Composition 

The  following  steps  shall  be  executed  prior  to  constructing  a  PT  Chapter  10  packet. 

1.  Truncate  the  number  of  packet  trailer  fill  bytes  to  no  more  than  three  bytes.  The 
number  of  fill  bytes  contained  in  a  PT  Chapter  10  packet  shall  be  restricted  to  a 
maximum  of  three  bytes. 

2.  Update  the  header  packet  length.  If  the  packet  trailer  fill  bytes  were  truncated,  the 
packet  length  shall  be  updated  accordingly. 

3.  Calculate  a  new  header  checksum.  If  the  packet  trailer  fill  bytes  were  truncated,  the 
header  checksum  shall  be  recalculated  using  the  updated  header  packet  length. 

4.  Calculate  a  new  data  checksum  (if  the  packet  trailer  contains  a  data  checksum).  If  the 
packet  trailer  fill  bytes  were  truncated  and  non-zero  packet  trailer  fill  bytes  were 
removed,  the  data  checksum  shall  be  recalculated  using  the  truncated  packet  trailer 
fill  bytes. 

Once  these  steps  are  executed,  the  Chapter  10  packet  header  shall  be  divided  into  the 
protected  and  unprotected  fields  as  described  above.  The  packet  trailer  bytes  field  shall  contain 
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the  sum  of  the  PT  Chapter  10  packet’s  secondary  header  length,  fill  bytes  length  (adjusted  to  a 
maximum  of  three  bytes),  and  data  checksum  length. 


If  the  size  of  the  Chapter  10  packet  exceeds  the  19-bit  limit,  the  data  length  shall  be  set  to 
modulo  524,288  (219)  of  the  Chapter  10  packet  length  and  multiple  Chapter  10  PTDPs  shall  be 
generated  using  the  PT  packet  fragmentation  method  described  in  Subsection  7.2.3. 


NOTE 


y 


Compared  to  the  original  Chapter  10  packet,  the  resulting  PT  Chapter  10 
packet  is  either  identical,  or  due  to  fill  byte  truncation,  shorter  than  the  original 
Chapter  10  packet.  If  fill  byte  truncation  occurred,  the  packet  length  and 
packet  header  checksum  will  be  recalculated  and  the  data  checksum  may  be 
recalculated;  however,  the  PT  Chapter  10  packet’s  data  content  remains 
unchanged  from  the  original  Chapter  10  packet. 


7.2.2A.2  Chapter  10  Packet  Reassembly 

A  Chapter  10  packet  may  be  reassembled  once  an  entire  PT  Chapter  10  packet  has  been 
reassembled  from  one  or  more  PTDPs  -  see  Subsection  7.2.3  for  details.  The  Chapter  10  packet 
header  shall  be  reassembled  after  Golay-decoding  is  performed  on  the  PT  Chapter  10  header’s 
protected  fields.  The  following  steps  shall  be  executed. 


1.  The  reassembled  Chapter  10  packet  sync  pattern  shall  be  set  to  0xEB25 
(16’bl  1 10101100100101)  as  specified  in  Chapter  10. 

2.  The  reassembled  Chapter  10  packet’s  packet  length  shall  be  calculated  as  follows: 


Packet  Length  —  ^  (length  in  each  PTDP  Fragment  Header ) 


3.  The  reassembled  Chapter  10  packet’s  data  length  shall  be  calculated  as  follows: 

Data  Length  —  calculated  Packet  Length  —  Packet  Header  Length  (24  bytes ) 
—  Packet  Trailer  Bytes 

Perform  this  comparison  to  validate  the  reassembled  Chapter  10  packet’s  data  length: 


PT  Chapter  10  Packet's  Data  Length  —  calculated  Data  Length  modulo  524,288 


NOTE 


y 


The  modulo  524,288  (219)  is  required  to  accommodate  original 
Chapter  10  packets  that  are  larger  than  524,288  bytes. 


The  following  steps  may  be  performed  to  verify  the  integrity  of  the  reassembled  Chapter 
10  packet. 

1.  The  packet  header  checksum  should  be  calculated  and  compared  to  the  reassembled 
Chapter  10  packet  header  checksum. 


2.  If  present,  the  data  checksum  in  the  packet  trailer  should  be  calculated  and  compared 
to  the  reassembled  Chapter  10  packet  data  checksum  in  the  packet  trailer. 


NOTE 


If  fill  byte  truncation  occurred  during  PT  Chapter  10  packet  composition,  the 
reassembled  Chapter  10  packet  length  and  packet  header  checksum  will  differ 
and  the  data  checksum  may  differ  from  the  original  Chapter  10  packet; 
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however,  the  reassembled  Chapter  10  packet’s  data  content  remains  unchanged 
from  the  original  Chapter  10  packet. 


7. 2. 2. 5  PT  Raw  Ethernet  Media  Access  Control  Frame  Packet 

The  PT  raw  Ethernet  MAC  frame  packet  contains  one  physical-layer  MAC  frame, 
starting  with  the  MAC  destination  address  and  ending  with  the  frame  check  sequence  inclusive, 
as  shown  in  Figure  7-10.  The  PT  raw  Ethernet  MAC  frame  packet  can  contain  any  kind  of 
message  data,  IPv4,  IPv6,  and  jumbo  messages.  No  extra  protection  is  applied  to  the  PT  raw 
Ethernet  MAC  frame  packet. 


Destination 

Source 

EEC 

(opt) 

3-9  bytes 

Frame  Check 
Sequence 

4  bytes 

MAC 

MAC 

Ethertype 

Payload 

Address 

6  bytes 

Address 

6  bytes 

2  bytes 

46  -  1500  bytes 

Figure  7-10.  PT  Raw  Ethernet  MAC  Frame  Packet 


1 .2.2.6  PT  Internet  Protocol  Packet 

The  PT  IP  packet  contains  one  IPv4  as  shown  in  Figure  7-11  or  one  IPv6  packet  as 
shown  in  Figure  7-12.  No  extra  protection  is  applied  to  the  PT  IP  packet. 


IPv4  Header 

IPv4  Payload 

20  -  36  bytes 

20  -  65,536  bytes 

Figure  7-11.  PT  IPv4  Packet 


IPv6  Header 

IPv6  Payload 

40  bytes 

40  -  65,536  bytes 

Figure  7-12.  PT  IPv6  Packet 


1 .2.2.1  PT  TmNSMessage  Packet 

The  PT  TmNSMessage  structure  contains  a  slightly  modified  version  of  a  Chapter  24 
TmNSMessage.  Figure  7-13  shows  the  Chapter  24  TmNSMessage  structure  and  Figure  7-14 
shows  the  PT  TmNSMessage  packet  structure. 
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McssagcDclinitionlD 

MessageDefinitionSequenceNumber 

MessageLength 

MessageTimestamp  (64  bits) 

ApplicationDefinedTields  (optional,  variable  length) 

MessagcPayload 

Figure  7-13.  Chapter  24  TmNSMessage  Structure 


PT 

TmNSMessage  — 

PT  TmNSMessage  Header  Protected  Fields 
(8x12  bits  unencoded  = 

8  x  24  bits  Golay-eneoded) 

Header 

PT  TmNSMessage  Header  Unprotected  Fields 
(12  bytes  +  ApplicationDefincdFiclds  length) 

MessagcPayload 

Figure  7-14.  PT  TmNSMessage  Packet  Structure 


The  original  Chapter  24  TmNSMessage  header  fields  are  partitioned  into  two  groups  for 
the  PT  TmNSMessage  header: 

•  Golay-encoded  protected  fields  that  protect  structure-critical  header  information; 

•  Unprotected  fields  (those  fields  not  part  of  the  protected  fields). 

The  PT  TmNSMessage  header  protected  fields  shall  consist  of  eight  12-bit  words  and 
shall  be  encoded  as  eight  24-bit  Golay  code  words  prior  to  insertion  into  the  PTDP  payload, 
encoded  msb  first  and  in  the  word  order  shown  in  Figure  7-15. 
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11  |  10  |  9  |  8 

7  \  6  \  5  \  4  3  \  2  \  1  \  0 

Word  0 

Message  Version 

OptionWordCount  MessageFlags  (3  -  0) 

Word  1 

MessageFlags  (15-4) 

Word  2 

Reserved 

MessageDefinitionID  (31  -  24) 

Word  3 

MessageDefinitionID  (23  -  12) 

Word  4 

MessageDefinitionID  (11  -0) 

Word  5 

MessageType 

MessageLength  (31  -  24) 

Word  6 

MessageLength  (23  -  12) 

Word  7 

MessageLength  (11  -  0) 

Figure  7-15.  PT  TmNSMessage  Header  Protected  Fields  (Unencoded) 

The  PT  TmNSMessage  header  unprotected  fields  shall  consist  of  12  bytes  plus  the 
ApplicationDefinedFields  (if  present)  as  shown  in  Figure  7-16. 

31 _ 24  |  23 _ 16  15 _ 8  \  7 _ 0_ 

MessageDefinitionSequenceNumber 

MessageTimestamp  (64  bits) 

ApplicationDefinedFields  (optional,  variable  length) 

Figure  7-16.  PT  TmNSMessage  Header  Unprotected  Fields 

7.2.3  PT  Package  Fragmentation 

If  a  PT  packet  requires  fragmentation,  each  PTDP  containing  a  PT  packet  fragment  shall 
be  inserted  sequentially  into  the  PTFR  stream.  Only  LLPs  can  be  inserted  in  between  a  PT 
packet’s  sequence  of  fragments  by  using  the  LLP  encapsulation  mechanism  as  described  in 
Subsection  7.4.2.  While  fragmentation  is  necessary  if  a  PT  packet’s  size  is  greater  than  or  equal 
to  64  kilobytes,  any  PT  packet  may  be  fragmented.  Figure  7-17  shows  PT  packet  fragmentation 
and  reassembly. 
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Figure  7-17.  PT  Packet  Fragmentation  and  Reassembly 


7.3  Packet  Telemetry  Data  Frame  Structure 

The  PTFR  is  a  fixed-length  frame  of  data  that  contains  a  portion  of  a  continuous  PTDP 
stream  as  represented  in  Figure  7-18. 


PTDP  Stream 

i  i 

TmNSMessage  ] 

PT  Data  Packet  [ 

Chapter  10 

PT  Data  Packet 

Ethernet  Frame 

PT  Data  Packet 

Chapter  10 

PT  Data  Packet 

\ 

\ / 

N 

7\ 

7 

1 

PTFR 

HDR 

PT  Data  Frame 
Payload 

PTFR 

HDR 

PT  Data  Frame 
Payload 

PTFR 

HDR 

PT  Data  Frame 
Payload 

1  PTFR 

1  HDR 

PT  Data  Frame  1 
Payload  1 

PTFR  Stream 

Figure  7-18.  Packet  Telemetry  Data  Frame  (PTFR)  Overview 


A  PTFR  consists  of  a  header  and  a  payload  as  shown  in  Figure  7-19. 


PTFR 

Header 


PTFR  Header,  Unprotected  Part 
(1  byte) 


PTFR,  Protected  Part 
(1x12  bits  unencoded  = 

1  x  24  bits  Golay-encoded) 


Figure  7-19.  PT  Data  Frame  Structure 


7.3.1  PTFR  Header 

The  PTFR  header  fields  are  partitioned  into  two  groups: 
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•  Unprotected  fields  that  contains  stream  and  version  information; 

•  Golay-encoded  protected  fields  that  protect  structure-critical  header  information. 

7 . 3 . 1 . 1  PTFR  Header  Unprotected  Fields 

The  PTFR  header  unprotected  fields  shall  consist  of  one  byte  as  shown  in  Figure  7-20. 


7 

6 

5 

4 

3 

2 

1 

0 

Stream  ID 

Reserved 

Version 

Figure  7-20.  PTFR  Header  Unprotected  Fields 


The  PTFR  header  unprotected  fields  are  defined  below. 

•  Stream  ID  (bits  7  -  4).  The  stream  ID  identifies  an  application- specific  stream. 

•  Reserved  (bits  3  -  2).  All  bits  shall  be  set  to  zero  (e.g.,  2’b00)  on  transmission; 
ignored  on  reception. 

•  Version  (bits  1  -  0).  The  PTFR  version: 


o 

2’b00: 

Version  1 

o 

2’b01: 

Reserved 

o 

2’blO: 

Reserved 

o 

2’bll: 

Reserved 

7 . 3 . 1 . 2  PTFR  Header  Protected  Fields 

The  PTFR  header  protected  fields  shall  consist  of  one  12-bit  word  and  shall  be  encoded 
as  one  24-bit  Golay  code  word  prior  to  insertion  into  the  PTDP  payload,  encoded  msb  first  and  in 
the  word  order  indicated  in  Figure  7-21. 


Figure  7-21.  PTFR  Header  Protected  Fields  (Unencoded) 

The  PTFR  header  protected  fields  are  defined  below. 

•  LL:  LLP  Exists  (bit  1 1)  -  see  Subsection  7.4.2  for  LLP  details 

o  l’bl:  indicates  the  PTFR  payload  contains  one  or  more  optional  LLPs  and  the 
closing  LLP  end  byte. 

o  1’bO:  indicates  no  LLP  and  no  LLP  end  byte  exist  in  the  PTFR  payload. 

•  Offset  to  First  PTDP  Header  (bits  10  -  0).  If  a  PTFR  contains  at  least  one  PTDP 
header,  this  field  specifies  a  byte  offset  to  the  first  byte  of  that  first  PTDP.  Otherwise, 
all  bits  shall  be  set  to  one  (11 ’bl  1111111111).  The  value  is  relative  to  the  first  data 
byte  following  the  PTFR  header  (e.g.,  the  value  of  zero  represents  the  first  byte 
following  the  PTFR  header).  See  Subsection  7.4.1  for  additional  information. 
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7.3.2  PTFR  Payload 

The  PTFR  payload  contains  zero  or  more  partial  or  complete  PTDPs  as  illustrated  in 
Figure  1-22.  Optional  LLPs  may  be  inserted  in  the  PTFR  payload  after  the  PTFR  header  (see 
Subsection  7.4.2  for  LLP  details). 

LLP  1  (variable  size,  optional) 

LLP  1  End  Byte  (1  byte,  present  if  LLP  1  is  present) 


LLP  M  (variable  size,  optional) 

LLP  M  End  Byte  (1  byte,  present  if  LLP  M  is  present) 
Partial  or  Complete  PTDP  1  (variable  size) 
Complete  PTDP  2  (variable  size) 


Complete  PTDP  N- 1  (variable  size) 

Complete  or  Partial  PTDP  N  (variable  size) 

Figure  7-22.  PTFR  Payload  Structure 

7.3.2. 1  Low-Latency  PTDP 

An  LLP  is  a  PTDP  having  low-latency  transmission  requirements  as  described  in 
Subsection  7.4.2.  If  one  or  more  LLPs  exist  in  a  PTFR,  the  first  LLP  is  placed  immediately  after 
the  PTFR  header. 

7. 3. 2. 2  Low-Latency  PTDP  End  Byte 

For  each  LLP  contained  within  a  PTFR,  an  LLP  end  byte  shall  immediately  follow  the 
LLP.  The  LLP  end  byte  identifies  if  another  LLP  follows  or  if  this  is  the  last  LLP  in  the  PTFR. 
The  LLP  end  byte  encoding  is  as  follows. 

•  8b’  11111111  (OxFF)  indicates  that  another  LLP  immediately  follows  this  byte. 

•  8b’00000000  (0x00)  indicates  there  are  no  more  LLPs  in  this  PTFR.  The  byte 
following  this  end  byte  is  the  first  byte  of  the  first  PTDP,  unless  the  LLP  end  byte 
is  the  PTFR’s  last  byte  (i.e.,  there  are  no  PTDPs  in  the  PTFR’s  payload). 

7. 3. 2.3  PTDPs  in  PTFR  Payload 

The  PTFR  payload  contains  zero  or  more  partial  or  complete  PTDPs  as  illustrated  in 
Figure  1-22.  The  initial  and  last  PTDPs  may  be  either  partial  or  complete  PTDPs.  See 
Subsection  7.4.1  for  details. 

7.4  Asynchronous  PTDP  Multiplexing 

A  PTFR  contains  asynchronously  inserted  PTDPs;  one  PTDP  may  span  multiple  PTFRs. 
The  PTDP  stream  contains  a  continuous  series  of  PTDPs;  the  start  of  a  PTDP  must  immediately 
follow  the  last  byte  of  a  previous  PTDP  as  illustrated  in  Figure  7-23. 
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_ Start  n 

fPTD 

1 

P  ' - - - 

1 

PTDP  Stream 

i  i 

TmNSMessage  j 

PT  Data  Packet  J 

Chapter  10 

PT  Data  Packet 

Ethernet  Frame 

PT  Data  Packet 

Chapter  10 

PT  Data  Packet 

\  \ 

. . i 

5 

7\ 

7 

PTFR 

HDR 

PT  Data  Frame 
Payload 

PTFR 

HDR 

PT  Data  Frame 
Payload  j 

PTFR 

HDR 

PT  Data  Frame 
Payload 

PTFR 

HDR 

PT  Data  Frame  j 
Payload  1 

PTFR  Stream 


Figure  7-23.  Start  of  PTDPs  Overview 


7.4.1  Standard  PTDP  Encapsulation 

If  the  start  of  a  PTDP  is  contained  within  a  PTFR,  the  PTFR  header  shall  contain  the 
offset  to  the  PTDP’s  first  byte.  If  there  are  multiple  PTDPs  in  the  PTFR,  the  PTFR  header  shall 
contain  the  offset  to  the  start  of  the  first  PTDP.  Since  one  PTDP  may  span  multiple  PTFRs,  the 
PTFR  header  may  not  contain  an  offset  to  a  PTDP.  See  Subsection  7.3.1.2  for  details.  An 
overview  of  the  standard  PTDP  encapsulation  mechanism  is  shown  in  Figure  7-24. 


Figure  7-24.  Standard  PTDP  Encapsulation  Overview 
7.4.2  Low-Latency  PTDP  Encapsulation 

The  transmission  of  a  long  PTDP  may  cause  too  long  of  latency  for  some  critical  data. 
Therefore,  an  LLP  mechanism  is  provided,  allowing  the  insertion  of  one  or  more  PTDPs  with 
low-latency  requirements  within  the  transmission  of  a  long  PTDP.  The  interrupted  long  PTDP  is 
resumed  immediately  after  the  LLP  part  of  the  PTLR. 

An  LLP  shall  not  span  multiple  PTLRs.  When  constructing  a  PTLR,  an  entire  LLP  and 
associated  end  byte  shall  fit  into  the  remaining  space  in  the  PTLR.  Ligure  7-25  shows  an 
overview  of  PTDP  encapsulation  with  LLPs. 


7-14 


Telemetry  Standards,  RCC  Standard  106-17  Chapter  7,  July  2017 


NOTE 

The  offset  to  the  first  PTDP  in  the  PTFR  header  is  not 

r 

necessarily  pointing  immediately  after  the  LLP. 

7.5  PT  Data  Frame  Transport 

To  insert  a  PTFR  into  a  Chapter  4  PCM  minor  frame,  each  PTFR  segment  is  byte-aligned 
and  inserted  into  the  PCM  minor  frame  as  a  byte  stream  with  the  msb  first  (as  shown  in  Figure 
1-26).  If  a  PTFR  segment’s  size  is  not  an  integral  number  of  bytes,  the  remaining  bits  at  the  end 
of  the  PTFR  segment  are  considered  fill  bits  and  should  be  ignored.  Each  PCM  minor  frame 
shall  contain  exactly  one  complete  PTFR  structure;  Figure  7-27  shows  a  PCM  minor  frame  with 
two  PTFR  segments. 
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Figure  7-27.  PCM  Minor  Frame  With  Two  PTFR  Segments 


If  no  PTDPs  are  available  for  transmission,  PTDPs  with  PT  fill  packets  shall  be  inserted 
into  the  PTFR  for  subsequent  insertion  into  the  PCM  minor  frame. 


NOTE 


All  PCM  minor  frame  overhead  words  such  as  the  Chapter  4  sync 
pattern  or  subframe  counters  are  not  considered  part  of  a  PTFR. 
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APPENDIX  7-A 

Extended  Binary  Golay  Code 


A.l.  Introduction 

A  single-bit  transmission  error  may  cause  excessive  data  loss  in  packet  telemetry.  If  the 
error  occurs  in  identification  or  structure  length  fields,  the  error  can  lead  to  misinterpretation  of  a 
packet  or  a  loss  of  a  series  of  packets. 

To  help  mitigate  potential  errors,  a  self-correcting  coding  called  extended  binary  Golay 
code  is  applied  to  structure-critical  elements  in  a  packet  telemetry  stream.  This  additional  coding 
provides  protection  of  the  packet  identification  and  length  information  and  supports  correction  of 
up  to  3-bit  transmission  errors  in  a  24-bit  sequence.  This  is  accomplished  by  encoding  12-bit 
words  into  24-bit  words. 

This  extended  binary  Golay  code,  G24  (sometimes  just  called  the  “Golay  code”  in  finite 
group  theory)  encodes  12  bits  of  data  in  a  24-bit  word  in  such  a  way  that  any  3-bit  errors  can  be 
corrected  or  any  7-bit  errors  can  be  detected.  In  standard  code  notation  the  codes  have 
parameters  (24,  12,  8)  corresponding  to  the  length  of  the  code  words,  the  dimension  of  the  code, 
and  the  minimum  Hamming  distance  between  two  code  words,  respectively. 1  The  coding  and 
decoding  of  the  Golay  code  is  illustrated  in  Figure  A-l. 


Figure  A-l.  Golay  Code  Encoding  and  Decoding 


The  following  sections  are  C  code  reference  implementation  and  define  the  required 
behavior  of  encoding  and  decoding  the  extended  binary  Golay  code. 


1  Golay,  Marcel  J.  E.  Notes  on  Digital  Coding  in  “Proceedings  of  the  IRE,”  1949,  v.37,  p.  657. 
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A.2.  Encoding  Golay  Code 

The  extended  binary  Golay  code  encoding  lookup  table  can  be  initialized  by  the 
InitGolayEncode()  function,  and  the  encoding  can  be  done  by  the  Encode(v)  macro  of  the 
following  C  code. 

#def ine  GOLAY_SIZE  0x1000 


//  Generator  matrix  :  parity  sub-generator  matrix  P  : 


uintl6_t  G_P[12]  =  { 

0xc75,  0x63b,  0xf68,  0x7b4, 
0x3da,  0xd99,  0x6cd,  0x367, 
0xdc6,  0xa97,  0x93e,  0x8eb 

}; 


/*  Binary  representation 


1 

1 

0 

0 

0 

1 

1 

1 

0 

1 

0 

1 

0 

1 

1 

0 

0 

0 

1 

1 

1 

0 

1 

1 

1 

1 

1 

1 

0 

1 

1 

0 

1 

0 

0 

0 

0 

1 

1 

1 

1 

0 

1 

1 

0 

1 

0 

0 

0 

0 

1 

1 

1 

1 

0 

1 

1 

0 

1 

0 

1 

1 

0 

1 

1 

0 

0 

1 

1 

0 

0 

1 

0 

1 

1 

0 

1 

1 

0 

0 

1 

1 

0 

1 

0 

0 

1 

1 

0 

1 

1 

0 

0 

1 

1 

1 

1 

1 

0 

1 

1 

1 

0 

0 

0 

1 

1 

0 

1 

0 

1 

0 

1 

0 

0 

1 

0 

1 

1 

1 

1 

0 

0 

1 

0 

0 

1 

1 

1 

1 

1 

0 

1 

0 

0 

0 

1 

1 

1 

0 

1 

0 

1 

1 

*/ 

uint32_t  EncodeTable [  GOLAY_SIZE  ];  //  Golay  encoding  table 

//  encode  a  12-bit  word  to  a  24-bit  Golay  code  word 
#define  Encode (v)  EncodeTable [v&Oxfff] 


//  initialize  the  Golay  encoding  lookup  table 
void  InitGolayEncode (  void  ) 

{ 


f or (  uint32_t  x=0;  x  <  GOLAY_SIZE;  x++  )  { 

//  generate  encode  LUT 
EncodeTable [x]  =  (x<<12)  ; 

for (  uint32_t  i=0;  i<12;  i++  )  { 

if (  ( x>> (11— i) )  &  1  ) 

EncodeTable [x]  A=  G_P[i]; 


A.3.  Decoding  Golay  Code 

The  extended  binary  Golay  code  decoding  lookup  tables  can  be  initialized  by  the 
InitGolayDecode()  function  of  the  following  C  code.  The  12-bit  decoded  and  corrected  word 
can  be  calculated  by  the  Decode(v)  macro  from  a  24-bit  code  word.  The  number  of  error  bits  in 
a  24-bit  code  word  can  be  gotten  by  the  Error(v)  macro  from  a  24-bit  code  word. 
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#def ine 


GOLAY  SIZE 


0x1000 


uintl6_t  SyndromeTable [  GOLAY_SIZE  ]; 
uintl 6_t  CorrectTable [  GOLAY_SIZE  ]; 
uint8_t  ErrorTable [  GOLAY_SIZE  ]; 


/ /  Syndrome  table 
//  correction  table 
//  number  of  error  bits  table 


#define  Syndrome2 (vl , v2 ) 
#define  Syndrome (v) 
#define  Errors2 (vl , v2 ) 
#define  Decode2 (vl , v2 ) 


(SyndromeTable [v2] A (vl) ) 

Syndrome2 ( ( (v) >>12) &0xfff , (v) &0xfff ) 
ErrorTable [ Syndrome2 (vl , v2 ) ] 

( (vl ) ACorrect Table [ Syndrome2 (vl , v2 ) ] ) 


//  get  the  number  of  error  bits  in  this  24-bit  code  word 
#define  Errors (v)  Errors2 ( ( (v) >>12) &0xfff , (v)&0xfff) 

//  get  the  12-bit  corrected  code  from  a  24-bit  code  word 
#define  Decode (v)  Decode2 ( ( (v) >>12) &0xfff , (v) &0xfff ) 

//  Parity  Check  matrix 
uintl 6_t  H_P[12]  =  { 

0xa4f,  0xf68,  0x7b4,  0x3da, 

Oxled,  0xab9,  0xfl3,  0xdc6, 

0x6e3,  0x93e,  0x49f,  0xc75 


/*  Binary  representation 


0  10 
111 


0  111 
0  0  11 


0  10  0 
0  110 
10  11 
110  1 


1111 
10  0  0 
0  10  0 
10  10 


0  0  0  1 
10  10 


1  1 
0  1 


1110 
10  11 
0  0  0  1 
110  0 


110  1 
10  0  1 
0  0  11 
0  110 


0  110 
10  0  1 
0  10  0 
110  0 


7 


1110 
0  0  11 
10  0  1 
0  111 


0  0  11 
1110 
1111 
0  10  1 


//  calculate  the  number  of  Is  in  a  24-bit  word 
uint8_t  OnesInCode (  uint32_t  code,  uint32_t  size 
{ 

uint8_t  ret  =  0; 

f or (  uint32_t  i=0;  i<size;  i++  )  { 

if (  (code>>i)  &  1  ) 
ret++; 


return  ret; 


void  InitGolayDecode (  void  ) 

{ 

f or (  uint32_t  x=0;  x  <  GOLAY_SIZE;  x++  )  { 

//  generate  syndrome  LUT 
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SyndromeTable [x] =0;  //  Default  value  of  the  Syndrome  LUT 

f or (  uint32_t  i=0;  i<12;  i++  )  { 

if (  (x>> (11—1) )  &  1  )  SyndromeTable [x]  A=  H_P[i]; 

ErrorTable [x]  =  4; 

CorrectTable [x] =0xf f f ; 


//  no  error  case 
ErrorTable [ 0 ]  =  0; 

CorrectTable [ 0 ] =  0; 

//  generate  all  error  codes  up  to  3  ones 
for (  int  i=0;  i<24;  i++  )  { 

for (  int  j=0;  j <2 4 ;  j++  )  { 

for (  int  k=0;  k<24;  k++  )  { 

uint32_t  error  =  ( 1 << i )  |  ( 1<< j )  |  ( 1 <<k ) ; 

uint32_t  syndrome  =  Syndrome (error ) ; 
CorrectTable [ syndrome ]  =  (error>>12)  &  Oxfff; 
ErrorTable [ syndrome ]  =  OnesInCode (error, 24 ) ; 


A.4.  Decoding  the  Golay  Code  (8,1,3) 

The  one-byte  0x00  or  Oxff  can  also  be  considered  as  a  binary  Golay  code  (8,1,3)-  It 
allows  correcting  the  0x00  or  Oxff  transmission  of  up  to  3-bit  errors,  and  detecting  4-bit  errors. 
The  (8,1,3)  code  decoding  lookup  tables  shall  be  initialized  by  the  InitGolay00FFDeeode() 
function,  and  the  decoding  can  be  done  by  the  DecodeOOFF(v)  macro  of  the  following  C  code. 

#def ine  B YTE_LUT_S I ZE  0x100 

uint8_t  DecodeOOFFTable [  BYTE_LUT_SIZE  ];  //  decode  0x00  or  Oxff  (8,1,3) 
uint8_t  ErrorOOFFTable [  BYTE_LUT_SIZE  ];  //  number  of  error  bits  (8,1,3) 

#define  DecodeOOFF (v)  DecodeOOFFTable [v] 

#define  ErrorOOFF (v)  ErrorOOFFTable [v] 

void  InitGolayOOFFDecode  (  void  ) 

{ 

//  generate  (8,1,3)  tables 
for(  uint32_t  i=0j  i<BYTE_LUT_SIZE;  i++  )  { 
uint32_t  j  =  OnesInCode(i,8); 

Decode00FFTable[i]  =  j  <=  4  ?  0  :  0xff; 

Error00FFTable[i]  =  j  <=  4  ?  j  :  8-j; 

} 

} 
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APPENDIX  7-B 
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*  *  *  END  OF  CHAPTER  7  *  *  * 
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